But if applications use undocumented features, or rely on bugs, or plain fly in the face of documentation (such as in the SimCity example), should be no onus on the system provider to continue to support that behaviour.

If you want to be confident about your program working in the future, write it according to the documented API, and following the portability guidelines that litter the net. This won’t safeguard you against reckless maintainers, but many (most?) library maintainers do care about API compatibility, and even ABI compatibility for the more core ones.

No, what I’ll understand is that Microsoft had no competition on the IBM PC for far too long, and that their operating system is pre-loaded when the hardware is purchased.

Backward compatibility is a noble goal to an extent, but in the extreme can be detrimental. We can see that now as we watch Microsoft take a half a decade to release a minor upgrade to an unstable, bug-ridden, and insecure operating system. Some things are not worth emulating.

While this might be true for the base system, it is certainly not true for all the apps you might want to run on top of it and that are not part of the distribution. In fact, the whole point of an operating system is to provide the infrastructure for running applications on top. These might or might not happen to be part of your distribution of choice.

It’s always important to remember that to the developer, binaries without the source are worthless. But it is equally important to remember that to the end user, source without (compatible!) binaries is worthless.

Check it out:
http://lcsd05.cs.tamu.edu/slides/keynote.pdf (pdf slideshow)
http://www.infoq.com/presentations/effective-api-design (webcast)

I agree 100% with G Fernandes comments. Applications should strive to maintain API compatibility and give very long deprecation cycles if a change is absolutely required. But trying to follow a MS Windows approach to the solution is bad path for all involved except the one group that gets the application. If a application chooses to use an undocumented or unexposed call, they risk breaking there own stuff. No application should be held responsible to maintain compatibility to is “private” interfeces.

Finally I have to agree with Simon Waters who inferred that the number of applications available on the shelves of Best Buy is a poor indicator of the success of the approach of MS has taken. In fact if you compared the number of available applications VS the total desktop market share, you would likely see that Linux has a huge advantage followed by OS X then Windows. But that is just an uneducated guess :)

Anyway, the point here is that backward compatibility is important but, as in most things, you need to find the right balance when moving a product forward.

By the way, it is the fist time that I read a linux insider talking well about microsoft. Things are really changing around here…

A good example might have been the JDBC API. If there is a problem in a specific driver implementation, clients do not have to change their code. The implementation of the offending driver changes to fix bad behavior.

Backward compatibility doesn’t suffer – all clients access the driver through the JDBC interface. The JDK doesn’t work around to accomodate bad driver implementations. The offending driver is fixed.

Voila! You have backward compatibility with good practice!